As computers have evolved from 66MHz to the 3+GHz today, the mouse has remained relatively unchanged. There have been only two major changes to the mouse since its inception: more buttons, and interface changes (PS/2, USB, Wireless) but the core interaction method has not changed. The touch pad mouse and the stick mouse have been designed for a laptop, but have not gained momentum outside of laptops. And most laptop users usually carry a USB mouse with the laptop as well.

Thus, as any engineer would, we wanted to the next step in this technology. For reasons mentioned in the introduction, an accelerometer based mouse system is a great option since:

1. It's cool
2. Provides health benefits

Initially, we planned on calculating position from the accelerometers. We hoped that this would enable us to accurately track the motion of the user's fingers and, with some work and a lot of caffeine, we could emulate a keyboard if an accelerometer was placed on each of the user's fingers. Unfortunately, the accelerometers were not keen on disclosing their position in space, and after two weeks of experimenting we had to abandon calculating position (and thus a keyboard implementation) and retreat to a tilt based mouse. We still maintain that if there was more time, and a bit more hardware, we can measure position reliably enough to design an “in-air“ keyboard.

There are obviously many options for mouse communications protocols, such as serial, PS/2, and USB. There are multiple reasons we chose PS/2 as our standard. First, we had no prior experience in developing the protocol, unlike RS-232 serial, so it provided a good challenge for our final project design. Secondly, we could draw power from the PS/2 port, giving our mouse the ability to stand alone without a dedicated power supply or batter. Finally, PS/2 can be easily adapted to fit USB using a simple $6 adapter we already owned. This way we can still get the usability of USB without having to learn the complicated USB standard.

It should be noted however, that there are some downfalls to PS/2 development that may make people in the future decide to program for RS-232 serial. Firstly, PS/2 requires the PC BIOS to detect the mouse and assign a device ID. Unfortunately this process usually occurs at boot up, and may require repeated boot ups of a PC for testing. A 476 group in 2002 built a utility for emulating a host PC, allowing one to bypass the re-booting problem. However, much of it is written in assembly for the 8515 micro-controller. We explain our suggestions for testing the PS/2 protocol in a later section of this report.

Below is a high level diagram of the mouse system:

Figure-1: High Level Design

The accelerometers are connected to the microcontroller through ADC channels 0 through 3 (port A of the ATmega32). The Y axis tilt accelerometer is placed such that it will read different G values when the hand is tilted around the Y axis (axis references shown in Figure 2). Tilting around the Y axis (tilting the hand side to side) will move the mouse pointer along the X axis. The same happens with X axis tilt accelerometer: it feels a different fraction of gravity based on how far the hand is tilted down or up (i.e. tilted along the X-axis). This will make the mouse pointer move along the Y axis.

Figure-2: Axis Reference

There are two more accelerometers placed just below the tip of the index and middle fingers. These accelerometers are oriented such that they read acceleration in the X axis direction. Thus, if the fingers are flicked as if you were closing them to form a fist, they read an acceleration proportional to the speed at which the user flicks the finger.

Most of the calculations in the MCU code are adding or subtracting certain correction constants to interpret the ADC reading. A lot more calculations (mainly integrations) were used to measure position from the accelerometers, but since that was eventually abandoned, the integration formulas are not included in our final code, although the older versions of the code show the calculations used for integration.

The interpreted value of the ADC is used to generate values for mouse_byte0, mouse_byte1, mouse_byte2 and mouse_byte3. These bytes are sent to the computer using the PS/2 protocol to move the mouse cursor and press buttons. Byte 1 contains X axis movement, and thus the interpreted readings from ADC 0 is plugged into here and Byte 2 is used for Y axis movement (so it gets the readings from ADC 1).

Throughout the code, only one timer was used - Timer 0. Timer 0 was set up to create a 20 usec time base that is used for button debouncing as well as setting up the clock for the PS/2 communication. The button debouncing is required even when you flick your finger to press the button since there is a sizeable amount of “ringing“ at the beginning and end of the motion. The particular reason that we use a 20 us timer is that the interrupt also runs the PS/2 state machines that control the clock and data outputs to the PC. The clock run at 12.5 kHz, giving a period of 80 us. Since the PS/2 state machines need to run at four points of the clock cycle (rising, high, falling, low), the period was divided by four to obtain 20 us. For more details on the PS/2 implementation, refer to the hardware and program design sections

Tektronix, Inc. patented an Inertial Mouse System on May 16th 1986. The abstract mentions that accelerometers will be used to calculate potion by integrating the output voltage twice (basically the same approach we were going to follow). This webpage has a more detailed description of the patent.

There are a few things to note about this patent. First, this was never really commercialized by Tektronix or anyone else. There are no accelerometer based mice in the market that use position to pinpoint the location of the user's finger or hand. Second: there is no mention of using tilt. There is a mention of calculating angular velocity by measuring differences in accelerometer read values, but nothing specific about using tilt.

Thus, our tilt mouse idea seems to not step on any patents. There is one company that has a tilt-based mouse system that is predominantly shown in Google searches. There is no indication on their website that they hold a patent for the tilt-based mouse system, so it does not seem like our product steps on their toes either. The interesting thing is that bosswave uses an accelerometer that is very similar to ours - we were initially going to use the accelerometer BossWave uses in their product.

One way our product pulls ahead of bosswave's product is that the buttons are not on the small ring you wear around your thumb. The buttons on our product are on separate fingers, so you do not have to curl them in weird ways to press the buttons on the ring. Of course, bosswave has a far better packaging system than we do. But if we had enough time and a slightly larger budget, we could have made a very nice package as well. Furthermore, their product sells for $80. We built ours in under $20, and this was an un-optimized version: by using a less powerful microcontroller, we can easily cut down our prototype's cost.

The PS/2 mouse standard was orignally developed for the Personal System/2 developed by IBM in the 1980's. It is an open interface with no legal restriction. As a result, it is still widely used and supported. In detail, the PS/2 interface is a bidirectional protocol allowing the device to tranfer movement and key-stroke updates to the host while the computer can send commands to the device. The PS/2 standard is also nice in that it allows for the host PC to power the device.